The present invention relates to communications networks. More particularly, and not by way of limitation, the present invention is directed to a system and method providing overload control in next generation networks.
Next Generation Networks (NGN) provide several real-time services. These services are based on a wide range of protocols over several servers. The applied protocols typically do not provide response or status codes that indicate processing overload. Furthermore, these protocols do not specify an overload control mechanism. Since the servers can experience processing overload (e.g., server failure, high rates of incoming service requests, etc.), the servers must be equipped with some form of overload detection and control.
Typically, load control is provided by building a mechanism into each protocol that needs it. However, it would be quicker and cheaper to solve this problem in a way that is independent of the protocols. A separate overload control protocol with associated load control functions called Generic Overload Control Application Protocol (GOCAP) exists, which detects processing overload, adapts and distributes restriction levels and applies restriction. The lack of overload management in NGNs is currently being addressed by the European Standards body, European Telecommunications Standards Institute (ETSI) within an architecture study within its Telecoms and Internet Converged Services and Protocols for Advanced Network (TISPAN) project. A document produced by the study, ETSI TISPAN, “Next Generation Networks; Architecture for Control of Processing Overload,” ETSI TR 182 015 V1.1.1. (2006-10) describes the architectural principles that are required to provide effective control of processing overload in networks compliant to a TISPAN NGN Architecture. The scope is limited to the control of processing overload at NGN processing resources. Overload may be caused by service requests coming from session-based or command-response applications. A mechanism controls the rate at which those applications send service requests to an overloaded resource. The study does not extend to the overload of transmission bandwidth, whether used for the user plane or for the control plane.
Furthermore, the TISPAN study identifies the main problem with overload is that rejecting fresh calls takes processing effort. Thus the effective throughput at an overloaded resource (i.e., admitted service requests/sec) must eventually fall as the load offered to it is increased which causes the node to allocate its time rejecting fresh demand. To prevent this from happening, it is necessary that controls external to the resource act to decrease the fresh offered load to the level at which its effective throughput is maximized. Suggested overload control design rules include internal overload control, external overload control, priority given to session release requests, explicit demand rejection, closed loop feedback control, location of control components, automatic destination control, and Service Level Agreement (SLA) enforcement. This study describes the nodal behaviors as well as the requirements for the GOCAP. The GOCAP is proposed to define an optional parallel interface to an existing control interface which supports the real time management of dynamic transaction request peaks between components in or interfacing to the control plane of a NGN.
Within another document, ETSI TISPAN, “Control of Processing Overload; Stage 2 Requirements”, ETSI TS 182 018 V2.0.0 (2008-01), it describes the specific TISPAN requirements for controls to manage overload of processing resources in NGNs. In particular, it addresses overload control between nearest neighbors.
However, current overload control algorithms throttle the call (or request) rate only after processing the messages passing through the node. There is no throttling mechanism which occurs prior to passing through the node. Therefore, existing algorithms are likely to waste valuable node resources processing messages that will never be successfully served in the end. This wastes network resources and degrades the network level capacity.
FIG. 1 is a simplified block diagram of a control mechanism implemented in a source 10 in an existing overload control system. The node, source 10, receives input traffic mix of two types: A and B, which after local processing, are intended for target 12 and target 14 respectively. If the input traffic is more than the source 10 is able to process, then the excess is dropped first through a throttle 16. However, if the input traffic mix between types A and B is significantly different from the ratio between targets 12 and 14's processing capacity, then a significant portion of the traffic admitted and processed by the source 10 will be dropped at the targets 12 and 14. Thus, the processing capacity used for these messages is wasted in the source 10.
As an example in FIG. 1, the source 10 has a capacity of 10 c/s and filters the input of 10 calls/sec (c/s) and statistically admits 5 calls/sec of both traffic types (in the same ratio as the input mix). The source then processes these 5+5 c/s. However, 4 c/s of type A destined for target 10 is considered an excess that is dropped.
There are other examples where this problem arises in other network scenarios. For example, in the Media Gateway-Telephony Softswitch Solution Gateway Control (MGW-TGC) context, which typically involves, inter-MGW calls, the off-hooks from an MGW that is overloaded are dropped more frequently than off-hooks from other MGWs. In an IP Multimedia subsystem (IMS) network, a Serving Cal Session Control Function (S-CSCF) handles both VoIP and Presence traffic and sends them to two different Application Servers (ASs). If both the ASs handling the Voice over IP (VoIP) traffic and the S-CSCF are overloaded because of the VoIP traffic, then some of the S-CSCF's processing capacity is wasted on VoIP traffic that the AS discards anyway. Another IMS scenario occurs when a Proxy CSCF (P-CSCF) node serves as a proxy for both home and roaming users. If both the AS serving the home users and the P-CSCF are overloaded, then some of the P-CSCF's capacity is spent on home user calls that will be blocked by the AS anyway, although roaming user calls in their stead still could have been served successfully by their respective home networks.
In addition, it is also feasible that the classification on the incoming side is based on the source and the classification on the outgoing side is some kind of traffic class. If the same AS handles both normal and emergency traffic at the same time, these requests arrive from different S-CSCF functional nodes (e.g., normal calls come from a CSCF, and emergency calls from an Emergency CSCF). The emergency calls could be prioritized above the normal traffic only after examining the sender S-CSCF's IP address, however such classification is not considered in current solutions.
GOCAP as a solution furthered by the ETSI TISPAN addresses some of these problems, but does have several shortcomings. GOCAP is missing the exact algorithm on how to filter the input traffic at the node's edge. As shown in FIG. 1 where the source 10 admits equal ratios (i.e., with the same filter weights), it is not optimal with wasted resources. The GOCAP's design relies on all nodes of the network to understand, propagate and act according to the control information sent by their peers. If only a single node does not follow the standard, then the whole overload control is damaged in that part of the network. GOCAP implies that a target may request different c/s limits for different traffic types. This is a problem if the source is not able to classify its input mix according to the same rules as the target, although both implement GOCAP properly. For example, an S-CSCF requests a P-CSCF to limit traffic in a particular user class, however the P-CSCF cannot determine whether any given message falls into that class.